ZeroMQ 消息丢失排查：模式语义、HWM 与慢连接者
ZeroMQ 的定位是"智能的 Socket 库"，不是完整的消息中间件：它的可靠性保障取决于所选 socket 模式，与应用层的补充设计强相关。当链路上出现消息丢失时，需要从模式语义、配置、网络到应用逻辑逐层排查。本文整理一套从整体到局部的排查流程，适合排查过 ZeroMQ 丢消息问题的开发者对照使用。
排查总览
第一步：定性问题
先明确丢失的模式，能大幅缩小排查范围：
- 全部丢失还是部分丢失？
- 持续发生还是偶发？
- 发送后立即丢失，还是在特定操作（如重启、新订阅者接入）后丢失？
第二步：检查 Socket 类型与模式
ZeroMQ 的可靠性高度依赖 socket 类型，这是排查的第一要务：
| Socket 类型 | 可靠性特征 | 可能导致丢失的原因 |
|---|---|---|
| REQ-REP | 锁步模式（请求-应答-请求-应答） | 一方不按顺序发送（如连续两次 send）或一方崩溃，整个对话死锁，后续消息全部"丢失" |
| PUB-SUB | 单向推送，无确认机制 | 默认不保证可靠：订阅者连接慢于发布者发送速度、或中途断开，都会丢消息——最常见的丢失场景 |
| PUSH-PULL | 负载均衡模式 | PUSH 端无法感知 PULL 端是否处理成功，worker 崩溃时其未拉取/处理中的消息丢失 |
| DEALER-ROUTER | 异步的 REQ-REP，更灵活 | 需要在应用层自行实现可靠性（序列号 + 确认） |
排查方法：审查代码中 zmq_socket() 的第一个参数，确认模式与业务的可靠性需求匹配。
第三步：检查高水位线（HWM）
HWM 是非常常见的偶发丢失原因。每个 socket 的发送/接收管道都有容量上限，达到 HWM 后 ZeroMQ 会静默丢弃新消息（PUB 类型的发送端）或阻塞（PUSH/REQ 类型的发送端，取决于 socket 类型）。默认值通常为 1000（ZeroMQ 3.x 起），高吞吐场景下容易触顶。
cpp
int hwm = 10000;
zmq_setsockopt(sender, ZMQ_SNDHWM, &hwm, sizeof(hwm));
zmq_setsockopt(receiver, ZMQ_RCVHWM, &hwm, sizeof(hwm));HWM 的详细语义（各 socket 类型的缓冲组合、丢弃与阻塞的分界）建议对照官方文档确认。注意：调大 HWM 只是治标，根本问题仍是消费速度跟不上生产速度——调大缓冲只是推迟了丢弃的发生点，内存占用却线性上升。
第四步：慢连接者问题（PUB-SUB 特有）
订阅者在发布者之后启动、或中途断开重连时，会错过它不在场期间发布的消息——PUB socket 默认不为后来的订阅者保留历史。
应对思路：
- 感知订阅者加入：XPUB 端开启
ZMQ_XPUB_VERBOSE。默认情况下 XPUB 只把每个主题的第一条订阅消息转发给应用，开启后所有订阅/退订消息（含重复订阅）都会转发，应用据此感知每个新订阅者并补发最新状态——这也是 Last Value Cache 模式的基础； zmq_proxy()设备：用中间代理缓存消息，缓解直连场景的丢失；- 升级消息系统：业务关键、不允许丢失的消息，改用原生支持持久化的消息队列（Kafka、RabbitMQ），或在应用层实现确认 + 重传。
第五步：深入排查
ZMQ_SOCKET_MONITOR：把连接建立/断开等底层事件通过一对内部 PAIR socket 转发出来，实时监控连接状态，判断消息丢失发生在哪个环节。注意在主循环里及时消费 monitor 事件，避免事件积压。检查所有 API 调用的返回值：ZeroMQ 不抛异常，靠返回值
-1+errno报错。每次zmq_send/zmq_recv/zmq_connect都要检查：
cpp
int rc = zmq_send(socket, message, len, flags);
if (rc == -1) {
if (errno == EAGAIN) { /* 非阻塞下无法立即发送（HWM 满） */ }
else if (errno == ETERM) { /* 上下文已终止 */ }
// 记录日志: zmq_strerror(errno)
}- 网络与资源：防火墙/安全组拦截端口；网络抖动导致频繁断连；
lsof -p <pid>检查文件描述符是否耗尽；消息大且 HWM 高时的内存压力。
根因与解决对照
| 根本原因 | 解决方案 |
|---|---|
| 模式选择错误（如用 PUB-SUB 却要求可靠） | 换 REQ-REP / DEALER-ROUTER，或应用层加确认（ACK）与重传 |
| HWM 满导致丢弃 | 优化消费者性能；适当调大 SNDHWM/RCVHWM；用 ZMQ_SNDTIMEO 设阻塞超时 |
| 慢连接者（PUB-SUB） | zmq_proxy 设备缓存；升级持久化消息队列 |
| 未处理错误返回值 | 强化错误处理，检查返回值并记录 errno |
| 网络问题 | zmq_socket_monitor 诊断；应用层心跳与重连 |
小结
ZeroMQ 的可靠性要由开发者根据所选模式在应用层补充设计：PUB-SUB 天生不保证送达，慢连接者丢消息是特性而非 bug；HWM 触顶的静默丢弃只能靠监控发现。业务关键、不允许丢失的消息，必须自己实现确认与重传，这是最根本的解决方案。